Web services play a key role in facilitating information exchange in network environments, and are relied upon to service network traffic round-the-clock. As a result, deploying a new version of a web service, such as an updated or improved version of the web service, must typically be performed in such a way as to maintain service continuity during the deployment process.
A service cluster hosting a web service will often include a load balanced tier of virtual machines (VMs) on each of which the web service is running concurrently. A conventional approach to deploying a new version of the web service includes testing the new version in a quality assurance (QA) environment, removing a VM from the load balancer rotation, replacing or over-writing the old version of the web service stored on the VM with the new version, and returning the VM having the new version of the web service to the load balancer rotation. That procedure is then typically repeated until all of the VMs running the web service have the new version installed.
The conventional deployment approach described above can be risky, however. For example, because the new version of the web service is typically tested in a QA environment, there remains some uncertainty about how the new web service will perform in production, i.e., on a VM in the load balancer rotation and receiving live traffic. Moreover, in the event of malfunction or failure of the new version of the web service, changes made to VM configuration settings during the deployment may require more than simple restoration of the old version of the web service software. As a result, the process of backing out a failed or underperforming software deployment may be labor intensive and time consuming, and in some instances may place service continuity at risk.